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Abstract. 

We prove that three strategy video games from the Sid Meier's Civilization series: Sid Meier’s Civiliza- 
tion: Beyond Earth, Sid Meier’s Civilization V, and Sid Meier’s Civilization VI, are Turing complete. 
We achieve this by building three universal Turing machines-one for each game-using only the elements 
present in the games, and using their internal rules and mechanics as the transition function. The exis- 
tence of such machines imply that under the assumptions made, the games are undecidable. We show 
constructions of these machines within a running game session, and we provide a sample execution of 
an algorithm-the three-state Busy Beaver-with one of our machines. 
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1 Introduction 


The Sid Meier's Civilization] series is a collection of turn-based strategy video games, with a focus 
on building and expanding an empire through technological, social, and diplomatic development. 
'The scale and scope of these games involve intricate rules and mechanics, along with multiple victory 
conditions, all of which makes them interesting from a computational point of view. 

In this paper we focus on leveraging the mechanics inherent to these games to build universal 
Turing machines. Universal Turing machines, or UTMs, are mathematical abstractions used in the 
rigorous study of mechanical computation. By definition, a UTM is able to execute any program 
that can be ran in a computer, and is effectively equivalent to a computer with unbounded memory. 

We introduce explicit constructions of UTMs for three installments of the Civilization series: 
Sid Meier's Civilization: Beyond Earth (Civ:BE from now on), Sid Meier's Civilization V (Civ:V), 
and Sid Meier’s Civilization VI (Civ:VI). Our only strong constraint is that the map size and turn 
limits must be infinite, which is in line with the requirements around a UTM. 

For the constructions of Civ: BE and Civ:V, we design UTMs that are relatively easy to visualize, 
although "large"-that is, the transition function has many instructions. We also describe, but not 
prove, smaller constructions. Finally, we note that an immediate consequence of the existence of an 
internal game state representing a UTM is undecidability of said game under the stated constraints. 
We provide constructions of each UTM in their respective games, and conclude by providing an ex- 
ample implementation and execution of the three-state Busy Beaver game [7] in the Turing machine 


built for Civ: BE. 


2 Background 


2.1 Turing machines and Turing completeness 


A Turing machine can be physically visualized as an automaton that executes instructions as dic- 
tated by a function ó, and that involve reading or writing to a tape of infinite length via a head. 


1 Preprint. This paper is for scholastic purposes only and the author's affiliations, past and present, should not be 
considered an endorsement. 
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Following the definition from Hopcroft et al. [5], they are defined as a 7-tuple (Q, T, 2,6, b, qo, F), 
where: 


— Qisa set of possible states that can be taken internally by the Turing machine. Namely, go € Q 
is the initial state, and F C Q is the set of final (or accepting) states. 

— T is the set of tape symbols on which the Turing machine can perform read/write operations. 
In particular, b € I’ is the blank symbol, and X C I’, b Z X is the set of symbols which may be 
initially placed in the tape. 

— ô: (Q\F) xI *QxIx{L, R} is the transition function. It is a partial function that takes in 
all states from the machine, along with the current read from the tape; it determines the next 
state to be taken by the Turing machine, as well as whether to move the head left (L) or right 
(R) along the tape. Note that not moving the tape can be trivially encoded in this definition. 


Turing machines are a mathematical model, and are limited in practice due to the infinite 
length requirement on the tape. On the other hand, the expressive power behind the theory of 
Turing machines allows for the rigorous study of computational processes. 

Concretely, since Turing machines are finite objects, it is possible to encode a Turing machine 
M; and use it as an input to a separate machine Mo, so that M» simulates M1. A (m, n)-universal 
Turing machine, or (m,n)-UTM, is a Turing machine that is able to simulate any other Turing 
machine, and such that |Q| = m,|I'| = n. The Church-Turing Thesis states that such a construct 
models precisely the act of computation-concretely, the set of functions that can be computed by a 
UTM is precisely the set of computable functions [8]. 

A collection of rules and objects under which a simulation of a UTM is possible is said to be 
Turing complete. Turing complete models of computation are varied, from mathematical models 
such as the A-calculus and the theory of -recursive functions; to other rule-based systems like 
Conway's Game of Life [2] and the card game Magic: The Gathering [8]; and even video games and 
other software such as Minesweeper [6] and Microsoft PowerPoint [10]. 


2.2 General Mechanics of Sid Meier’s: Civilization 


All of the Sid Meier's: Civilization installments are turn-based, alternating, multiplayer games. The 
players are in charge of an empireP| and good management of resources and relationships with other 
players are key to achieve one of the multiple possible victory conditions allowable. These victories 
(e.g., Diplomatic, Militaristic, Scientific) and their specific mechanics are of interest when analyzing 
the computational complexity of the game, but not when designing a Turing machine. In this paper 
we limit ourselves to describing the rules governing the actions of units on the map, and which are 
common to the games that we will be analyzing. Since the naming conventions for the components 
of the games vary across them-even though these components may serve the same purpose-we also 
introduce a unified notation. 

The games that we will be discussing (Civ:BE, Civ:V, and Civ:VI) are played on a finite map 
divided in hexagonal tiles, or heres. Hexes are composed of different geographical types (e.g., oceans, 
deserts, plains), and may contain certain features (e.g., forests, oil) dependent on the initial condi- 
tions of the game. 

All tiles have an inherent resource yield, which is used by the player to maintain the units and 
buildings that they own, and to acquire more advanced technologies and social policies. Some exam- 
ples of these resources are Food, Production, Culture, and Science. One or more player-controlled 
units known as Workers are usually tasked to build improvements on a tile, which alters their yields. 


3 [n the case of Civ:BE, an extrasolar colony. 


As an example, technologies are acquired with Science, and Workers can build improvements on 
tiles (e.g. an Academy) to increase their Science yield. 

With some notable exceptions, described in the following section, Workers may only build im- 
provements in tiles owned by a City. A City can be seen as a one-tile special improvement, and has 
three main duties: to produce (“train”) units, to control and expand the boundaries of the owner’s 
frontiers, and to produces Citizens to work the tiles and their improvements. Citizens may only 
work the tiles owned by the City, but players are able to micromanage the placement of Citizens to 
alter their resource yield. 

It is important to note that on every turn, the player executes all or some of the actions available 
to them, such as building improvements, researching technologies and social policies, and focuses on 
the overall management of the empire. On the other hand, the specific types and mechanics around 
Cities, resources, features, available improvements, technologies and social policies vary from game 
to game. They will be discussed in detail in the next section, as they will be the key for building 
our UTMs. All of the UTMs are built inside a running game session, and leverage the concepts 


described here. 


3 Civ:BE, Civ:V, and Civ: VI are Turing Complete 
For this section, the following two assumptions hold: 


Assumption 1 The number of turns in Civ: BE, Civ: V, and Civ: VI is infinite, and there is only 
one player in the game. 


Assumption 2 The map extends infinitely in either direction. 


The rationale behind Assumption [1|is related to the fact that another player may interfere with 
the computation by-say-attacking the Workers, or reaching any of the victory conditions before 
the Turing machine terminates. Likewise, Assumption [2] is due to the fact that we intend to utilize 
the map as the tape for the UTM. We will discuss the feasibility of these assumptions in Section 5} 
For now, it suffices to note that Assumption |l|is easily achievable within the game itself; and 
Assumption [2] is a requirement present in all UTM constructions, and inherent to the definition of 
a Turing machine. 


3.1 A (10,3)-UTM in Civ:BE 


For the construction of this UTM, we rely on two Workers carrying out instructions on separate, 
non-overlapping sections of the map: one keeps track of states, and another acts as the head. The 
latter operates over the tape, which we consider to be the rest of the map. We do not require the 
player to own any of the tiles on the tape. However, the state hexes are finite and must be owned by 
the player. Building any improvement in Civ:BE takes a certain amount of turns, but the Workers 
may build and repair any number of them. 


The Tape: The tape is a continuous strip over the entire map, save for the state tiles, and without 
loss of generality, we assume that it is comprised of flat, traversable, hexes. Flatness is needed because 
irregular terrain requires more movement points to traverse. The set of symbols I’ is based off specific 
improvements that can be added and removed indefinitely by the tape Worker anywhere on the map- 
namely, Roads. The tape Worker adds and removes Roads according to the transition function, and 
a fast-moving unit (in this case, a Rover) pillages it. Note that for this setup to work, the Worker and 
the Rover will must move at the same time. Then, I’ = (No Improvement, Road, Pillaged Road}. 


The States: We assume that the player has at least nine flat, desert, unimproved tiles which 
will act as the states. Desert is required because we map states to the resource yields provided 
by a specific improvement-the Terrascape. Income from other tile types may interfere with state 
tracking. Moreover, we assume the player has unlocked the civic (social policy) Ecoscaping, which 
provides +1 Food, Production, and Culture for every Terrascape built, along with the relevant 
technology ( Terraforming) required to build them. The Worker in charge of the states builds and 
remove Terrascapes on the state hexes, and the normalized change in Culture income serves as the 
state value q; € Q, Q — (0,...,9]. 
See Figure [I] for a sample construction. 
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Fig. 1. A (10,3)-UTM built within Civ:BE. The tape is located to the left of the image, and runs from the top middle 
of the screen to the bottom left. It currently has Roads (symbols in I") on every hex, except one pillaged Road. The 
head (the tape Worker and the Rover) are positioned in the middle of the screen, reading the symbol “Road’-the 
read is implicit, but can also be seen from the “Build Actions” menu, which does not allow the player to build a Road 
on an existing Road. The UTM is in state q2, since the total Culture yield in this turn is Cy = 7 (the purple number, 
top right on the image). Each Terrascape (lush green tiles on the right) contributes 3 Culture, and the base Culture 
yield is C. = 1, so q2 = (Ct — C.)/3 = 2. For this particular map, desert tiles appear as solid ice. 


Theorem 1. Suppose Assumptions [1] and |2] hold. Also suppose that there is a section of the map 
disjoint from the rest, owned by the player, and comprised of at least nine desert, unimproved tiles; 
and that the player is able to build and maintain at least nine worked Terrascapes, has a constant 
base per-turn Culture yield C,, and has the Ecoscaping civic. 

Then the following is a (10,3)-UTM: 


Q = {0,...,9}, (1) 
I = (No Improvement, Road, Pillaged Road}, (2) 


where qi € Q is the difference in the normalized Culture yields in turn t, qi = C, — Cx, and the 
transition function 6 is as described in Table [6.1] 


Proof. A full proof can be found in Appendix It consists of two parts: building a bijection 
between the transition function and an existing (10, 3)J-UTM, and then showing that the time delay 
between our construction and the aforementioned UTM is bounded by a constant. 


Remark 1. This is not the only possible UTM that can be built within Civ:BE. Unlocking the 
ability of a worker to add and remove Miasma expands the set of symbols from the tape yields a 
(7, 4)-UTM with a smaller set of instructions. 


There are a few things to highlight from this construction, and that will apply to the rest of the 
UTMs presented in this paper. First, while the base constant yield is hard to achieve in-game, it 
is relatively simple to account for: simply execute every move at the beginning of the turn, record 
Cx, and then execute the transition function for the UTM. Even better, counting the number of 
Terrascapes on a specific tile would work just as well. 

Second, remark that this UTM, along with the others presented in the paper, may be fully 
automated by using the API provided by the publisher. Manual simulation is, although tiresome, 
also possible, as displayed in Section 

Finally, it is well-known in the field of theoretical computer science that it is possible to have a 
UTM with no states, by simply increasing the number of heads and using a different section of the 
tape as scratch work. Such a construction will be equivalent to ours. 


3.2 A (10, 3)-UTM in Civ: V 


We follow the same approach as in Theorem |1| one Worker builds improvements (Roads and Rail- 
roads) on tiles to simulate the symbols on a tape, and another Worker improves and unimproves 
tiles to encode the internal state of the machine based on the relative yield of a specific resource. 
Just as in Civ:BE, building any improvement in Civ:V takes a certain amount of turns, but the 
Workers may build any number of them. 


The Tape: Asin Theorem [1] the tape is a continuous strip over the entire map, and it is comprised 
of flat, traversable, hexes. The set of symbols I’ is the two improvements that can be built by the 
tape Worker anywhere on the map: Roads and Railroads. Building a Railroad requires that the 
player has unlocked the Engineering technology. Then I’ = {No Improvement, Road, Railroad}. 


The States: In Civ:V it is no longer possible to remove improvements outside of Roads and 
Railroads, so we must rely on these improvements for state tracking. The Worker in charge of the 
states builds and removes Railroads to encode the state. This is carried out in a reserved section of 
the map (e.g., inside a City), and the total number of Railroads serves as the state value q; € Q, 


Q 40, ...., 91. 


Theorem 2. Suppose Assumptions [1] and [2] hold. Also suppose that there is a section of the map 
disjoint from the rest, owned by the player, and comprised of at least nine tiles. Assume that the 
player has the Engineering technology. 

Then the following is a (10,3)-UTM: 


Q = {0,...,9}, 
I = (No Improvement, Road, Railroad}, 
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where qi € Q is the total number of Railroads in the nine tiles, and the transition function 6 is 
as described in Table|6.2 


Proof. In Appendix [6.2] it is similar to the proof of Theorem |1| 


2. UNIT NEEDS ORDERS Y 
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Fig. 2. A (10, 3)-UTM built within Civ:V. It is in the state q2 since the City (left) has two Railroads built: one on 
the tile with the elephant and another on the plantation. In this case, the area reserved for state tracking is every 
tile owned by the City. The head (the rightmost Worker, near the top) is positioned over a Railroad hex with two 
Roads adjacent to it. 


Remark 2. Just as in Theorem |1| it is possible to use a fast-moving pillaging unit (e.g., a Knight) 
and the ability of Workers to build Forts, to expand the symbol set of the machine to a (5, 5)-UTM. 
'This machine would have an even smaller set of instructions. 


3.3 A (48,2)-UTM in Civ:VI 


In Civ:VI, Worker units are unable to build improvements indefinitely. It is still possible to build an 
UTM in Civ:VI if we use the Cities as the head and the tape, and leave the Worker to encode only 
the position of the head. The Citizens are micromanaged to “write” symbols to the tape, by putting 
them to work specific hexes. As before, we maintain a separate set of tiles to act as the states. 

In CiV:VI, there is no upper limit on the number of Cities founded by the player, as long as 
they are all placed at least 4 hexes away from other Cities. Under Assumption |1| this allows us to 
found an infinite number of Cities via a unit called a Settler. These units are trained by the City, 
and once the Settler has been created, the City loses a citizen. Provided there is enough Food, a 
new Citizen is born in the City after a certain number of turns. No Settlers can be trained if the 
City has only one citizen. 


Founding a City consumes the Settler, and the City takes its place. The tiles owned at this time 
are set to be the six closest hexes[/] and two Citizens spawn: one works the tile with the highest- 
possible yield of combined resources, and another—which cannot be retasked-the City itself. All of 
this occurs on the same turn. 

We will utilize the available tiles and the Citizens to build our (48, 2)-UTM. A sample construc- 
tion can be seen in Figure |3| Although our construction is more complicated than the previous 
UTMs, we note that all of this is achievable with the built-in mechanics and rules of the game. 


The Tape: Assume, for simplicity, that the map is comprised of flat hexes, all of which are of the 
floodplains category. A single, uninterrupted, grassland strip is the only exception. The tape is then 
the grassland tiles owned by the player. Cities are collocated three hexes away from one another 
over the grassland strip. The symbols on the tape (I = {“is being worked", “is not being worked” }) 
are the number of Citizens working on a given grassland tile. 

Our design is unconventional since the tape is not infinite by design. Instead, we consider a 
transition to be concluded if the City has at least three Citizens. We cap the growth of any new 
City to four Citizens: one that works in the City (and cannot be moved), two to work the tape tiles, 
and one that will act as a Settler if need be. If a Settler has been created, then the growth of the 
City is capped at three. Note that this doubles as a marker for the end of the tape. 

Every time the transition function issues a “move right” command, the controller first checks the 
population size of the City, and the position of the Worker unit. There are four possible cases: 


— The City has three Citizens, and the Worker is on the rightmost (resp. leftmost) hex. Then the 
Worker moves right (left), to the next City, and is placed on the leftmost (rightmost) hex. 

— The City has four Citizens. This is the end of the tape and a Settler must be trained to expand 
the tape. After it is spawned, the City is capped to three, and the Settler is issued the command 
to move right (resp. left) four hexes, build a City, and grow it to four population. The Worker 
is issued the command to move right (left) three hexes, and wait until the City is grown. 


The “move left" command is symmetric to the above. 


The States: Just as in Theorems |1| and |2| we rely on a set of hexes disjoint to the tape for our 
state tracking, and we utilize the relative yield of a specific resource (Faith) to encode it. We assume 
the player has built 23 Monasteries without any adjacent districts. Monasteries, when worked under 
these conditions, yield +2 Faith per turn, and are only buildable if the player has ever allied with 
the Armagh City-State. We also require the player to have built 23 Farms without any adjacent 
districts} Transitioning from one state to the other requires the player to re-assign as many workers 
as possible to adjust the difference in Faith yields from the beginning of time, which in turn realizes 
(part of) the state q; € Q. 


Theorem 3. Suppose Assumptions [1] and [2] hold. Also suppose that the map contains an infinite 
strip of grassland tiles, with floodplaims above and below, and that the player owns one City placed in 
the grassland strip. Also assume that there is a set of tiles disjoint to the strip, owned by the player, 
and with 23 Monasteries and 23 Farms without any adjacent districts. Let F, be the constant base 
Faith yield per turn for this player. 


^ This action technically builds a City Center, but we will forgo this distinction. Players who play as Russia will 
found Cities with five extra hexes. 

5 As in the other constructions, we impose specific requirements for our proofs and their generalizability. In practice, 
any resource yield (e.g., Culture) or improvement (e.g., Ethiopia's Rock-Hewn Church; Egypt's Sphinx; India’s 
Stepwell) would work. 


Then, if there are no in-game natural disasters occuring during the time of the execution, the 
following Turing machine is a (48, 2)-UTM: 


Q ={0n,...,23n} U (0b, .. . , 235], (5) 
I = {Is Being Worked, Is Not Being Worked}, (6) 


where qix € Q is the difference in the Faith yields at turn t, qi = F; — Fi; x € {n,b} indicates 
whether it is needed to build a new Settler, and the transition function 6 is as described in Table|6.3 


Proof. In Appendix |6.3} 
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Fig. 3. Diagram of a (48,2)-UTM built with Civ:VI components and rules. The bottom two Cities act as the state 
of the machine, and each of the Cities on the top strip contain two cells from the tape. The head position is tracked 
by the Worker. Refer to Figure|5|for a working in-game construction. 


In Appendix |6.4| we discuss an alternative implementation involving two players at war with 
each other, and which requires fewer cities being built. 


Remark 3. This construction works with every civilization and update released up to and including 
the April 2021 Update. It is, however, much more brittle than the other two UTMs introduced in 
this paper. 


Corollary 1. Civ:BE, Civ: V, and Civ: VI are undecidable under Assumptions|1| and |2 


Proof. Immediate from the proofs of T'heorems |1| |2| and |3| The existence of an in-game state that 
simulates a UTM implies undecidability. 


Table 1. Transition function for the three-state Turing machine corresponding to BB-3, and the equivalent Civ:BE 
construction. For the Turing machine, the notation is read as (state, read; write, move, set state). For the Civ:BE 
machine, A corresponds to the normalized change in Culture per turn. 


Civ:BE state (A; tape read) | Command to Workers (tape; state) BB-3 TM 
0; No Improvement Build a Road and move R; Build a Terrascape qo0; 1Rqi 
0; Road Build a Road and move L; Build 2 Terrascapes qol; lLqo 
1; No Improvement Build a Road and move L; Remove a Terrascape q10; 1Lqo 
1; Road Build a Road and move R; No build qıl; LRqı 
2; No Improvement Build a Road and move L; Remove a Terrascape q20;1Lqi 
2; Road HALT q21; 1R HALT 


4 Example: The Busy Beaver in Civ:BE 


The Busy Beaver game, as described by Radó [7], is a game in theoretical computer science. It 
challenges the “player” (a Turing machine or a person) to find a halting Turing machine with a 
specified number of states n, such that it writes the most number of 1s in the tape out of all 
possible n-state Turing machines. The winner is referred to as the n*^ Busy Beaver, or BB-n. Note 
that all the Turing machines playing the Busy Beaver game have, by definition, only two symbols, 
r = {0,1}. 

Finding whether a given Turing machine is a Busy Beaver is undecidable, but small Busy Beavers 
are often used to demonstrate how a Turing machine works. In particular, BB-3 is a three-state 
(Q = {qo, q1, q2}), two-symbol (I = {0,1}) Turing machine with a transition function as described 
in Table 

Given the Turing completeness of Civ:BE, we can build BB-3 within the game itself. An 
equivalent construction with our Civ:BE (10,3)-UTM has the states Q = {0,1,2}, symbols l = 
{No Improvement, Road}, and with a transition function as described in TableH] A sample execution 
of BB-3 within Civ:BE can be seen in Figure 4[9| 


5 Discussion 


We introduced UTMs for Civ:BE, Civ:V, and Civ:VI, and showed their ability to execute an ar- 
bitrary algorithm by running BB-3 on our Civ:BE UTM. We also proved that, as an immediate 
consequence of the existence of a UTM within their internal state, these games are undecidable 
under the unbounded turn limit and map size assumptions. 

'Turing completeness in a system goes beyond a mere curiosity, however: the work here showed 
that there might exist states of the game where it is undecidable to determine whether there exists 
a sequence of moves that yields a specific state; and, more importantly, that it is possible to write 
and execute programs in-game. 

That being said, any realistic construction of a Turing machine is physically limited by the 
hardware. It follows that if these assumptions were relaxed, Civ: BE, Civ:V, and Civ:VI are equivalent 
to a linear-bounded automaton. Even then, the games are characterized by long sessions, complex 
rules, multiple victory conditions, varying scales, and imperfect information, all of which leave room 
for further analysis from a computational complexity perspective. While other video games have 
been studied, such as classic Nintendo games and traditional board games (both of which led 
to the development of powerful theoretical tools [4]), most 4X video games have not analyzed from 
this angle. 


5 An animated version of this execution can be found in https: //adewynter.github.io/notes/img/BB3.gif 


Fig. 4. Sample execution of BB-3 with a Civ:BE Turing machine. The machine executes 11 instructions t1,...,t11 
before halting. Top left: state corresponding to tı = qo0;1Rq. Top right: state for the machine at t2 = q10; 1Lqo. 
Bottom left: state for the machine at tio = gol; 1Lq2. Bottom right: state for the machine at tii = q21; HALT. 


A good understanding of the computational complexity associated with these games is important 
for the development of more efficient and engaging AI systems; and their inherent long-term sim- 
ulative nature at the macro and micro-management level makes them correlate into contemporary 
problems in computer science, such as multiple-scale forecasting and online learning. 
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6 Appendices 


6.1 Civ:BE UTM Proof 


In this section we prove Theorem |1| Table shows a bijective function between the Civ:BE 
UTM transition function and the (10,3)-UTM program from Rogozhin [9]. The execution of every 
command takes at most the time taken to build (or remove) five Terrascapes and one Road. Let 
T and M the number of turns needed to build a Terrascape and a Road, respectively. Repairing 
and removing improvements takes only one turn. Then the maximum overhead, for any instruction, 
will be at most 5T + M turns. It follows that this construction is less efficient than a UTM by a 


constant factor. 


Table 2. Bijection between the UTM from Theorem [1] and Rogozhin's (10, 3)-UTM. For the Turing machine, the 
notation is read as (state, read; write, move, set state). For the Civ:BE machine, A corresponds to the change in 


Culture per turn relative to the player's base yield. 


Civ:BE state (A; tape read) | Command to Workers (tape; state) (10, 3)-UTM 
0; No Improvement Build a Road and move R; No build qo0; 1 Rqo 
0; Road Remove Improvement and move L; Build a Terrascape qol;0Lqi 
0; Pillaged Road No Improvement and move R; Build 3 Terrascapes qob; bRq3 
1; No Improvement No Improvement and move L; Build a Terrascape m0; 0Lqo 
1; Road Remove Improvement and move L; No build q11;0Lqi 
1; Pillaged Road No Improvement and move L; No build qib;bLqi 
2; No Improvement No Improvement and move L; Remove a Terrascape q20;0Lqi 
2; Road Pillage the Road and move L; Build 3 Terrascapes q21;bLqs 
2; Pillaged Road No Improvement and move R; Remove 2 Terrascapes q2b; b qo 
3; No Improvement Build a Road and move R; Remove 3 Terrascapes q30; 1Rqo 
3; Road No Improvement and move R; Build a Terrascape qal; lRq4 
3; Pillaged Road Repair the Road and move L; No build q3b; 1Lq3 
4; No Improvement Build a Road, Pillage it, and move L; Remove 2 Terrascapes q40; bLqo 
4; Road No Improvement and move R; No build q41; lRqa 
4; Pillaged Road No Improvement and move R; No build qab; b qa 
5; No Improvement Build a Road and move L; Build a Terrascape q50; 1Lqe 
5; Road No Improvement and move L; No build q51; lLqs 
5; Pillaged Road No Improvement and move L; No build qsb; bLqs 
6; No Improvement No Improvement and move R; Build a Terrascape q60; 0Rqz 
6; Road HALT qel; HALT 
6; Pillaged Road No Improvement and move L; Build 2 Terrascapes qeb; bLqa 
7; No Improvement Build a Road and move L; Remove 2 Terrascapes q70;1Lqs 
7; Road No Improvement and move R; No build qzl;lRqz 
7; Pillaged Road No Improvement and move R; No build q7zb; b qz 
8; No Improvement Build a Road and move L; Build a Terrascape qs0; 1Lqo 
8; Road Remove Improvement and move R; Build a Terrascape qs1; 0Rqo 
8; Pillaged Road Remove Improvement and move L; Remove 5 Terrascapes qsb; 0Lqa 
9; No Improvement No Improvement and move R; Remove 5 Terrascapes q90; 0Rq4 
9; Road Remove Improvement and move R; No build q91; 0Rqo 
9; Pillaged Road No Improvement and move R; Remove a Terrascape qob; b qa 


6.2 Civ: V UTM Proof 


In this section we prove Theorem |2| Table [6.2] shows a bijective function between a Civ: V UTM 
transition function and the (10, 3)-UTM program from Rogozhin [9]. The execution of every com- 


mand will take at most the time taken to build (or remove) five Railroads, in addition to removing 
a Railroad and building a Road. This is because the mechanics of Civ:V do not allow the Workers 
to build a Road on a Railroad tile, so the Railroad must be removed first. This last action takes 
one turn. Let Brr > 1 be the cost of building a Railroad. The Worker in charge of states will have 
to build at most 3 Railroads; and the Worker in charge of the tape will have to at most remove a 
Road and build a Railroad instead, at a cost of 1 + B,, turns. Then the maximum overhead, for 
any instruction, is at most 4B,,+1 turns. It follows that this construction, like the UTM presented 
in Theorem [1] is less efficient than a UTM by only a constant factor. 


Table 3. Bijection between the UTM from Theorem D] and Rogozhin's (10, 3)-UTM. For the Turing machine, the 
notation is read as (state, read; write, move, set state). For the Civ: V machine, A corresponds to the number of 


Railroads in the state tiles. 


Civ:V state (A; tape read) | Command to Workers (tape; state) (10, 3)-UTM 
0; No Improvement Build a Road and move R; No build qo ; 01, Rao 
0; Road Remove Improvement and move L; Build a Railroad qo ; 10, Lqi 
0; Railroad No Improvement and move R; Build 3 Railroads qo ; bb, Rag 
1; No Improvement No Improvement and move L; Build a Railroad qı ; 00, Lqo 
1; Road Remove Improvement and move L; No build qı ; 10, La 
1; Railroad No Improvement and move L; No build qı ; bb, La 
2; No Improvement No Improvement and move L; Remove a Railroad q2 ; 00, La 
2; Road Build a Railroad and move L; Build 3 Railroads q2 ; 1b, Las 
2; Railroad No Improvement and move R; Remove 2 Railroads q2 ; bb, Rao 
3; No Improvement Build a Road and move R; Remove 3 Railroads qa ; 01, Rao 
3; Road No Improvement and move R; Build a Railroad q3 ; 11, Rq4 
3; Magrail Build a Road and move L; No build q3 ; b1, Lqa 
4; No Improvement Build a Railroad and move L; Remove 2 Railroads q4 ; 0b, Lgo 
4; Road No Improvement and move R; No build q4 ; 11, Rq4 
4; Railroad No Improvement and move R; No build qa ; bb, Raa 
5; No Improvement Build a Road and move L; Build a Railroad q50; 1Lqe 
5; Road No Improvement and move L; No build q51; lLqs 
5; Railroad No Improvement and move L; No build qsb; bLqs 
6; No Improvement No Improvement and move R; Build a Railroad q60; ORqz 
6; Road HALT qsl; HALT 
6; Railroad No Improvement and move L; Build 2 Railroads qeb; bLqa 
7; No Improvement Build a Road and move L; Remove 2 Railroads q70; 1Lqs 
7; Road No Improvement and move R; No build qzl;lRqz 
7; Railroad No Improvement and move R; No build q7b; bRqz 
8; No Improvement Build a Road and move L; Build a Railroad qs0; 1Lqo 
8; Road Remove Improvement and move R; Build a Railroad qs1; 0Rqo 
8; Railroad Remove Improvement and move L; Remove 5 Railroads qsb; 0Lqs 
9; No Improvement No Improvement and move R; Remove 5 Railroads q90; ORqa 
9; Road Remove Improvement and move R; No build q91; 0Rqo 
9; Railroad No Improvement and move R; Remove a Railroad qob; bRqs 


6.3 Civ: VI (48, 2)-UTM Proof 


In this section we present a partial proof of Theorem [3] Table [6.3] shows a bijective function between 
the Civ: VI UTM and Rogozhin’s (24, 2)-UTM. However, the mechanics around expanding cities are 
left out, as it is understood that any R or L command would have an extra branching statement to 


test the population size and build the new Settler, thus making Table|6.3]a (48, 2)-UTM. Concretely, 
let sz, s! be states of the machine at some turn t, with n € s; and b € s; being the only distinction 
between them. Then s; is equivalent to executing s;, training a Settler, founding a City, and growing 
it to four population, and then executing s;41. On the other hand, s; would immediately execute 
St+1- 

Each Citizen in a City consumes 2 Food per turn, so at any point in time the City will need at 
most 8 Food per turn. The City itself has a base yield of 2 (+2 since it is on grassland), and both 
grassland tiles being worked at the same time will provide 4 Food. This yields a maximum Food 
per turn of 8. It is easy to see that this is also the minimum possible amount of Food produced by 
the City, since floodplains provide +3 food. Thus maintaining a City as an operational unit of the 
tape is feasible. 

Let L be the length of the tape at any given time. Then the number of Cities by the player is 
given by L/2, and the cost of training a new Settler (in Production units) will be 152+ 50, or S(L) 
turns. Let C be the number of turns required to grow a City to 8 population. It takes a Settler 
3 turns to found a new City. Then the total overhead for this UTM is given by C 4- S(L) 4- 3. It 
follows that this UTM is linearly less efficient than a UTM. 


Remark 4. The linear slowdown provided by the cost of every Settler makes this UTM significantly 
more inefficient than the other UTMs presented in this paper. 


This construction can be achieved in-game. See Figure [5] for an example. 


6.4 An Alternative Civ:VI (48, 2)-UTM 


In this scenario, we consider two players at war with each other. One player must be playing as 
Rome, whose unique ability is that Cities founded within 15 hexes of another City with a trading 
post, build an automatic road connecting them and a trading post. 

The only change to the construction in Theorem[jis that instead of tracking symbols by assigning 
Citizens to hexes, we maintain the road as the tape. The Roman player builds cities and repairs 
roads with a Worker, and the second player uses a military unit to pillage the roads. Then the set 
of symbols is l = {Has working road", “Has pillaged road"). Assuming that the players never do 
anything to affect the computation (e.g., capturing the Workers or Settlers), this construction is 
equivalent to the one described in the previous sections. The need for a second player is clear given 
that players cannot pillage improvements within their own borders. 


Table 4. Relation between the UTM from Theorem |3] and Rogozhin’s (24, 2)-UTM, for the states not requiring a 
new Settler. For the Turing machine, the notation is read as (state, read; write, move, set state). For the Civ: VI 


machine, A is the change in Faith from the player's base yield, and the command “Work n Monasteries/Farms” 
involves reassigning Citizens to Farms or Monasteries as needed. 

Civ:VI state (A; tape read) | Command to Workers (tape; state) (24, 2)-UTM 
0; Is Not Being Worked Is Not Being Worked, move R; Work 5 more Monasteries q10; 0Rqs 
0; Is Being Worked Is Being Worked, move R; Work 2 more Monasteries qil;lHqgo 
1; Is Not Being Worked Is Being Worked, move R; Work 0 more Monasteries q20; 1Rqi 
1; Is Being Worked Is Being Worked, move L; Work 2 more Monasteries qol;lLqa 
2; Is Not Being Worked Is Not Being Worked, move L; Work 2 more Monasteries q30; 0Lqa 
2; Is Being Worked Is Not Being Worked, move L; Work 0 more Monasteries q31; 0Lqo 
3; Is Not Being Worked Is Being Worked, move L; Work 9 more Monasteries q40; 1Lqi2 
3; Is Being Worked Is Not Being Worked, move L; Work 6 more Monasteries q41; 0Lqo 
4; Is Not Being Worked Is Being Worked, move R; Work 3 more Farms q50; 1Rqi 
4; Is Being Worked Is Not Being Worked, move L; Work 2 more Monasteries q51; 0Lqc 
5; Is Not Being Worked Is Not Being Worked, move L; Work 2 more Monasteries q60; 0Lqz 
5; Is Being Worked Is Being Worked, move L; Work 2 more Monasteries q61; lLqz 
6; Is Not Being Worked Is Being Worked, move L; Work 2 more Monasteries q70; 1Lqs 
6; Is Being Worked Is Not Being Worked, move L; Work 0 more Monasteries q71; 0Lqe 
7; Is Not Being Worked Is Not Being Worked, move L; Work 0 more Monasteries qs0; 0Lqz 
7; Is Being Worked Is Being Worked, move R; Work 5 more Farms qal; LRq2 
8; Is Not Being Worked Is Not Being Worked, move R; Work 11 more Monasteries q90; 0Rq19 
8; Is Being Worked Is Being Worked, move L; Work 4 more Farms gol; 1Lqa 
9; Is Not Being Worked Is Being Worked, move L; Work 5 more Farms q100; 1Lq4 
9; Is Being Worked Is Not Being Worked, move R; Work 4 more Monasteries qiol;0Rqi3 
10;Is Not Being Worked Is Not Being Worked, move L; Work 6 more Farms q110; 0Lqa 
10;Is Being Worked HALT quil; HALT 
11;Is Not Being Worked Is Not Being Worked, move R; Work 8 more Monasteries q120; 0Rq19 
11;Is Being Worked Is Being Worked, move L; Work 3 more Monasteries qi21;lLqia 
12; Is Not Being Worked Is Not Being Worked, move R; Work 2 more Farms q30; 0Rq10 
12; Is Being Worked Is Being Worked, move R; Work 12 more Monasteries q131; 1 qoa 
13; Is Not Being Worked Is Not Being Worked, move L; Work 2 more Monasteries qia0; 0Lqis 
13; Is Being Worked Is Being Worked, move L; Work 2 more Farms qi4l;lLqii 
14; Is Not Being Worked Is Not Being Worked, move R; Work 2 more Monasteries q150; 0Rq16 
14; Is Being Worked Is Being Worked, move R; Work 3 more Monasteries qıs l1; LRqı7 
15; Is Not Being Worked Is Not Being Worked, move R; Work 0 more Monasteries qı60; ORqı5 
15; Is Being Worked Is Being Worked, move R; Work 5 more Farms qıs 1; 1Raq10 
16; Is Not Being Worked Is Not Being Worked, move R; Work 0 more Monasteries qı70; 0Rq16 
16; Is Being Worked Is Being Worked, move R; Work 5 more Monasteries qi;l;lRqoi 
17; Is Not Being Worked Is Not Being Worked, move R; Work 2 more Monasteries q180; 0Rq19 
17; Is Being Worked Is Being Worked, move R; Work 3 more Monasteries q181; 1 qoo 
18; Is Not Being Worked Is Being Worked, move L; Work 15 more Farms 4190; 1L qa 
18; Is Being Worked Is Being Worked, move R; Work 0 more Monasteries q191; 1Rqis 
19; Is Not Being Worked Is Being Worked, move R; Work 1 more Farms q200; 1Rqı8 
19; Is Being Worked Is Not Being Worked, move R; Work 1 more Farms q201; ORqı8 
20; Is Not Being Worked Is Not Being Worked, move R; Work 2 more Monasteries q210; 0 qo» 
20; Is Being Worked Is Being Worked, move R; Work 3 more Monasteries q211; 1 qos 
21; Is Not Being Worked Is Being Worked, move L; Work 1 more Monasteries q220; 1Lqio 
21; Is Being Worked Is Being Worked, move R; Work 0 more Monasteries q221; lRqoi 
22; Is Not Being Worked Is Being Worked, move R; Work 1 more Farms q230; 1 qoi 
22; Is Being Worked Is Not Being Worked, move R; Work 1 more Farms q231; 0Rqo21 
23; Is Not Being Worked Is Not Being Worked, move R; Work 10 more Farms q240; 0Rqi3 
23; Is Being Worked Is Not Being Worked, move L; Work 20 more Farms q241; 0Lqa 


Fig. 5. A (48, 2)-UTM built within Civ:VI. Top: the UTM in-game, with three Cities acting as the states and two as 
the tape. Bottom right: one of the Cities holding the state, with 8 Monasteries and 9 Farms. Bottom left: The tape 
being read (right hex; Worker not pictured) with a state of “Is Being Worked”. 


